Amazon Connect の同時通話数が上限に達した場合にどういう挙動になるのか検証してみた
こんにちは。
コンサルティング部 繁松です。
Amazon Connectの同時通話数が上限に達した場合にどういう挙動になるのか検証してみました。
AWSでは以下のように記載があります。
インスタンスあたりの同時アクティブコールのクォータを超えた場合、問い合わせは順序変更音 (高速の話し中の音) になり、着信番号への転送パスが利用できないことを示します。
[高速の話し中の音]など、上限に達した場合のイメージがつかなかったので実際に検証してみました。
検証方法
以下の問い合わせがカウントされるので、同一のコネクトインスタンスで発信と着信を行い検証してみます。
- 問い合わせフローで処理される
- キューで待機中
- エージェントによって処理される
- 発信通話
発信用のルーティングプロファイルに設定したユーザーと
着信用のルーティングプロファイルに設定したユーザーを作成し検証しました。
今回使用するコネクトインスタンスの同時同時通話数のクォータはデフォルトの10になっています。
検証してみた
同時通話数10の検証
まずは発信用5ユーザーと着信用5ユーザーで通話をしてみます。
Cloudwatchメトリクスを確認します。
ConcurrentCallsが10
ConcurrentCallsPercentageが1(100%)になったことを確認しました。
同時通話数10の時に発信を検証
同時通話数数10の状態で発信を検証してみます。
発信に失敗しました。
発信側の呼び出し音は鳴るのですが、4~5回ほど鳴ったところで切れました。
着信側は着信音も鳴らず、反応はありませんでした。
Cloudwatchメトリクスを確認します。
ConcurrentCallsが11
ConcurrentCallsPercentageが1.1(110%)になっていました。
同時通話数10の時に着信を検証
今度は同時通話数10の状態で着信を検証してみます。
同時通話数が10の状態で、別のAmazon Connectインスタンスから発信を行いました。
1件目の着信は着信音が鳴り電話を取ることができました。
さらに追加でもう1件着信を検証してみます。
発信側の呼出音が1回鳴ったところで切れてしまいました。
着信側は着信音も鳴らず、反応はありませんでした。
Cloudwatchメトリクスを確認します。
ConcurrentCallsが11
ConcurrentCallsPercentageが1.1(110%)になっていました。
さいごに
同時通話数のクォータを超えると発信は出来なくなり、着信は1件であればクォータを超えても受けることが確認できましたが、検証方法によって違っていたり、今回はたまたま着信を受けれたという可能性もあるので基本的には同時通話数のクォータを超えた場合は繋がらなくなるということがわかりました。
高速の話し中の音は特殊な音がなるようなことはなかったので、電話が切れた後の音（プープーと鳴る音）のことを指しているのではないかと思われます。（憶測です）
以上、繁松でした。
